home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Programmer Power Tools
/
Programmer Power Tools.iso
/
c
/
scsidrvr.arc
/
scsi.doc
< prev
next >
Wrap
Text File
|
1989-02-10
|
7KB
|
197 lines
INTRODUCTION:
This package contains three things:
1. A library of routines to interface to an Ampex Megastore PC SCSI
host adapter, written in Turbo C 1.5.
2. A generic MSDOS device driver, written in C and a little assembler.
3. An actual device driver for SCSI disks that uses 1 and 2 above.
Feel free to distribute this however you like.
THE AMPEX MEGASTORE HOST ADAPTOR:
The Ampex Megastore SCSI host adapter is a relatively "dumb" adapter.
Its virtue is that you can get one for $15 or so from Halted Specialities,
in Santa Clara, CA. It also has supporting software (what you have here)
that will let you use it to talk to SCSI disks, tapes, etc., hooked up to
your PC. I use one to communicate with two hard disks and a tape drive on
my AT&T PC6300.
This board comes with no documentation. Here is what I have learned:
The board uses I/O ports 0x320 to 0x323. These addresses clash with
the standard PC hard disk adaptor addresses. However, you can set
a switch or two on the board to relocate these addresses to 0X620 to
0x623. You will have to change a #define in scsi.c if you do this.
Unfortunately, I forget which switches on the board change the address.
Try them and find out.
The board also uses DMA channel 3, and an interrupt line. However,
the included code does not use the interrupt, or allow the board to
generate it. There are jumpers on the board to change the DMA or interrupt
numbers, if necessary. If the DMA channel is changed, code in scsi.c
will need a little bit of surgery.
Remove the EPROM on the board! The code in it seems to require a special
non-standard SCSI controller to work.
Here is a description of what the I/O ports do, as deduced by me:
Address Read Write
----------------------------------------------------------------------
0x320: Data Data
0x321: SCSI Control Lines Activate SCSI RESET line
0x322: Clear SCSI SEL, RESET Activate SCSI SEL line
0x323: XXXXX Enable DMA
Here is more info on reading port 321:
Bit Signal
-----------------------------
0 A switch on the board (I forget which)
1 Another switch
2 ???
3 SCSI MSG line
4 SCSI BSY line
5 SCSI C/D line
6 SCSI R/W line
7 SCSI REQ line
Writing any value to ports 321 and 322 seems to trigger the desired function.
See the code in scsi.c for how these signals are used. The functionality
provided in scsi.c should complete enough so that you do not have to worry
about the above information.
THE SCSI CODE:
Scsi.c contains two routines:
void scsiop(struct scsireq *req);
void scsiopv(struct scsivreq *req);
The first one is passed a pointer to a structure of data describing
a SCSI operation, and does it. The second one does the same thing,
but allows you to specify multiple data buffers in separate segments.
This allows you to send or receive more than 64K of data in one operation.
These is the structure that is passed to scsiop():
struct scsireq {
char far *dptr;
char far *cptr;
unsigned dlen;
char busid;
int error;
int timeout;
};
Dptr points to your data buffer. If the command you are executing
reads or writes no data, this can be NULL.
Cptr points to your command bytes for the SCSI operation.
The code will read as many command bytes from here as the SCSI
device asks for.
Dlen is the length of the data buffer. If you have more than 64K-1
bytes of data, use scsiopv() instead. The code will not read or write
past the end of the buffer. If the SCSI device tries to, an overrun
error will be generated.
Busid is the SCSI bus ID that the command will be sent to.
Upon return, error will be filled in with an error code.
Timeout is the number of .1 second units that the code should wait
before giving up and generating a timeout error. Specifying zero
will give a default five-second timeout. This timing depends on
loops in the code, and will have to be adjusted for extra fast or
slow PCs. It is correct for a 8 MHz V30.
Here is the meaning of the error word:
The low 8 bits contain the SCSI Status byte generated by the
SCSI device at the end of the transaction. The upper 8 bits
are as follows:
/* scsireq error bits */
#define S_BUSERROR 0x8000
#define S_BADSTATUS 0x4000
#define S_BADMESSAGE 0x2000
#define S_NOCONNECT 0x1000
#define S_TIMEOUT 0x0800
#define S_OVERRUN 0x0400
#define S_BADTRANS 0x0200
Note that these bits represent hardware errors or errors in the SCSI
protocol itself. Errors in the device, such as a bad block,
will cause a non-zero Status byte to be generated. The SCSI
Get Sense command will have to be used to find out more.
These are the arguments to scsiopv():
struct scsivreq {
struct scsibuf far *bufptr;
char far *cptr;
char busid;
int error;
int timeout;
};
struct scsibuf {
char far *dptr;
unsigned dlen;
};
Scsiopv() works the same as scsiop(), except that instead of taking
a single pointer to a data buffer, it takes a pointer to a list
of data buffers of varying lengths. The last buffer in the list
should have a length of zero and a NULL address. These buffers
will be read or written in order.
THE MSDOS DEVICE DRIVER CODE:
The makefile included describes how to make the SCSI disk device driver
in this package. The tricky code is generic, and by changing a couple of,
files, you can make your own device driver.
The files driasm.s, driver.h, and null.c, and they way the makefile
compiles and links them, should not be changed. The file dheader.s
should have to be modified only if you need to make a character device
instead of a block device. The file driver3.c should be modified
to do what you need your driver to do. The only procedure called externally
in this file is dointr(). It is passed a pointer to the request header
that describes what should be done. The current version basically
vectors to a seperate procedure for each request type. You should probably
keep this arrangement, and change as little code as possible. The file
scsi.c is part of this driver, but would of course be omitted if you
were not using a SCSI device. Note that making "dtest" with the makefile
should produce error-free compiles and link if everything is written correctly.
The file dtest.c can be added to to make a program that will test your driver
without having to load it at boot time.
All of the above assumes you know enough about how device drivers are
supposed to be written. I recommend the book "Advanced MS-DOS" by Microsoft
Press as a good reference for learning this.
Good Luck,
Doug Braun
7976 W. Zayante Rd.
Felton, CA 95018